perm filename MAIL.BH[UP,DOC]44 blob
sn#458042 filedate 1979-07-05 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00025 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00004 00002 M A I L
C00005 00003 MAIL: The MAIL program
C00012 00004 MAIL: Command Format
C00020 00005 MAIL: Destinations and Destination Lists
C00030 00006 MAIL: Message Formats
C00039 00007 MAIL: Message File Formats
C00042 00008 MAIL: Command Switches
C00056 00009 MAIL: Dates and Times
C00065 00010 MAIL: Wildcard Dates and Expiration Counts
C00068 00011 MAIL: Mail to Other ARPA Network Hosts
C00079 00012 MAIL: The MAIL Command
C00084 00013 MAIL: The SEND Command
C00087 00014 MAIL: The REMIND Command
C00089 00015 MAIL: The GRIPE Command
C00090 00016 MAIL: The EVENT Command
C00094 00017 α MAIL: The PLAN Command
C00097 00018 MAIL: The RETRY Command
C00099 00019 MAIL: The LATER Command
C00105 00020 MAIL: The BATCH Command
C00115 00021 MAIL: The REENTER Error Recovery Facility
C00120 00022 MAIL: Hand-Holding Mode
C00122 00023 MAIL: Interfacing to MAIL from Other Programs
C00132 00024 MAIL: The CANCEL Command
C00134 00025 MAIL: The RCV Command
C00159 ENDMK
C⊗;
M A I L
This documentation is taken from Appendix 4 of the Monitor Command Manual,
which can be found online in the file MONCOM.BH[UP,DOC] or in print as
SAILON 54.5.
See also E.ALS[UP,DOC] on the use of E in reading mail files and sending
messages.
MAIL: The MAIL program
The MAIL program is used to send messages to users and sometimes to
arbitrary disk files for special purposes. The program is invoked by one of
several monitor commands, depending on the function desired:
MAIL send a message to one or more message files
SEND send a message to the terminals of one or more users
GRIPE send a message complaining about a system problem
REMIND schedule a message to be sent at some later time
PLAN create a file describing how to find you when not logged in
EVENT send a message to all users about an event on a given date
BATCH schedule the execution of a command string at some later time
LATER schedule the execution of a given program at some later time
RETRY send any messages which were queued by earlier failing operations
The commands MAIL, SEND, and GRIPE may be given when not logged in, so that
people who are not authorized users of our system can use them to
communicate with us. A user who is not logged in will be asked for his
name, which will be included in the header of the message. However, users
who are not logged in may not use wildcard (send to all users) or ARPA
network destinations.
The commands MAIL, SEND, and REMIND require a list of destinations
(recipients of the message). All of the commands except LATER and RETRY
require some message text and also can be modified by the use of certain
optional switches, either applied globally (all destinations) or just to a
particular destination. The commands REMIND, PLAN, EVENT, and BATCH all
require a date and/or time which can be included by itself or in a global
/DATE or /TIME switch. (Any date given must appear before any time given,
whether in switches or not. See the section below on dates and times.)
LATER takes up to four specific arguments which describe the program to be
run and when it is to be run; these will be described on page 19.
RETRY takes no arguments at all; it merely looks for queued mail originating
from the current user and tries once again to send each such message (this
will be done automatically if RETRY is not used).
The normal command syntax includes all necessary information on one or more
lines without prompting. There is an alternative format, called
hand-holding mode, in which each piece of information required is prompted
for separately. Hand-holding mode is more verbose and time-consuming to
use, but may be less confusing to new users. It is invoked by typing just
the command of interest without any arguments, and will be described in a
separate section. What follows here assumes that the normal syntax is being
used.
Before explaining the complete range of command options, here are a few
sample commands:
SEND BH Want to have dinner?
This is a very simple example of a command with one destination and no
option switches. It types the message "Want to have dinner?" on BH's
terminal if he is logged in, along with a header indicating who sent the
message. If BH is not logged in, MAIL asks if the message should be mailed
instead of sent.
MAIL/DIST @NL Language group meeting Tuesday at 3pm.
This command mails the message "Language group ..." to the mail files of the
users listed in the file NL.DIS or NL or NL.DIS[P,DOC] (the [P,DOC] file
directory contains lists of users by project group). The first file in that
list which exists is used. The message will include the standard header
indicating who sent the message and when, and also (because of the /DIST
switch) a line indicating to whom the message is being sent.
REMIND/DATE=10-*-* . Rent due tomorrow
This command reminds the user who isssued the command (because of the "."
destination meaning self) to pay the rent on the tenth day of each month of
every year. The reminder is both mailed and sent each time, and expires
after 50 times. (These are default conditions modifiable by switches.)
MAIL: Command Format
The command format for all MAIL commands except LATER and RETRY is shown
below. The formats for the LATER and RETRY commands are explained in the
sections on those commands beginning on page 18.
<command & global switches> <destinations & local switches> <message>
The <destinations & local switches> part only applies to the MAIL, SEND, and
REMIND command. Destinations and destination lists will be described in the
next section.
The message text can be provided in any of three ways: (1) a one-line
message can be included after the destinations on the command line and ended
with <CR>; (2) if no message specification is given on the command line (or
the same line as the last destination for a multi-line command), MAIL asks
for a message to be entered from the terminal, ending with the end-of-file
character (<CONTROL><META><LF> from a Stanford display terminal or Imlac,
<control>Z otherwise); (3) if the notation
@file.ext[prj,prg]
is used on the command line after the last destination, the message text is
taken from the specified file. If no extension is typed, the extension .TXT
is tried first, and then a blank extension. To force the use of a filename
with no extension, type the dot but no extension, for example:
@file.[prj,prg]
The file may contain an E directory or SOS line numbers, which will not be
included in the message.
If something not starting with "@" follows the destination list on the
command line, it is taken as the message text. This makes single-line
messages more convenient to enter. If you start to enter a single-line
message, and decide you need more than one line after all, end the command
line with <LF> instead of <CR> and you will be allowed to continue the
message on later lines.
When entering a message, the usual line editing facilities are available.
In addition, if the <bs> key is typed when the input line is empty (i.e., at
the beginning of a new line), the last line typed is loaded into the line
editor (Stanford displays) or input buffer (non-displays) and the cursor is
positioned at the end of that line. The text of that line is deleted from
the accumulated message. The effect is that a carriage return can be
deleted by <bs> like an ordinary character. It is possible to back up
another line by doing another <bs> after clearing the newly reloaded line.
This procedure destroys the lines that followed the one to which you back
up, and the backup is only possible for a small (about 30) number of lines.
When entering a message from a Stanford display terminal, a better facility
is available for correcting errors in the command or in the message more
than one line before the current line. Typing <CONTROL><META>E at the end
of a line of message text will cause a file called MAIL$E.TXT to be written
on your login disk area (not alias) with the command, switches, and
destination list that you gave on page 2, and the message text up to the
<CONTROL><META>E on page 3. Then E is run automatically on this file to
allow you to edit the text and/or command. E will start up pointing at page
3 of the file, but you can modify the command or destinations by editing
page 2 (there will be a directory page). When you are finished editing the
message and command, type to E the command <CONTROL>XRUN to restart the MAIL
program automatically and send the message as edited. The MAIL$E.TXT file
is automatically deleted after the message is sent. Note: if you
accidentally or purposefully exit from E without saying <CONTROL>XRUN, you
can still send the message from MAIL$E.TXT by simply editing that file with
E (using /R if you don't need to further edit the message or command) and
then giving E the command <CONTROL>XRSYS MAIL, which will run MAIL to send
the message and delete the file.
The character <altmode> cannot appear in a message (because it is a line
editor activator and would confuse some mail-reading programs). If an
altmode is seen in the message text as input, it is changed into a dollar
sign ($). Also, the character <formfeed> cannot appear in a message
(because it would mess up the E-format of mail files). If a formfeed is
seen in the message text as input, it is changed into an exclamation point
(!).
If the /SUBJECT switch is used to include a subject line in the message
header, the subject is taken from the first text line entered: for a file,
the first line of the file is the subject; what would otherwise be a
single-line message is taken as the subject line for a multi-line message to
follow. If no message is provided on the command line, you are prompted for
a subject line and then for the message text.
MAIL: Destinations and Destination Lists
The commands MAIL, SEND, and REMIND require one or more recipients, or
destinations, specified in a list called the destination list. The
destinations should be separated by commas. The list may extend over more
than one line if the lines before the last end with comma. (Any characters
from a semicolon to the following linefeed are ignored.) The following
types of destinations may be used:
prg programmer name of local user
. yourself
* notice for all users
name real name (or leading substring) of local user
name % host user at another ARPA network host
% host sticky ARPA network host to be used for following names
#fil.ext[pj,pg] (MAIL only) arbitrary file to receive message
TTYn (SEND only) terminal to receive message
n (SEND only) job number to receive message
@fil.ext[pj,pg] file containing destination list
ARPA* (SEND only) all users logged in via ARPA network
The form "prg" in the above list must be one to three letters and digits,
the first of which is a letter (upper and lower case letters are
equivalent). The forms "name" in the above list must consist of either any
number of letters, digits, and hyphens, starting with a letter, or of
arbitrary characters enclosed in quotation marks ("...") or downarrows
(↓...↓). In the SEND command, the TTYn form may optionally be followed by a
colon.
ARPA network hosts are specified by host name (1 to 12 letters, digits, and
hyphens starting with a letter) or by decimal host number. If the host name
is used it can be abbreviated by enough characters to identify it uniquely.
Many hosts have short nicknames recognized by the network programs at
Stanford. Mail will only be sent to a host specified by name if the host is
listed in our host table as a server (that is, a host which accepts incoming
connections).
A host may be specified for a single destination, using the "name%host"
notation, or a sticky host may be specified by just "%host". A sticky host
will apply (until another sticky host is specified) to all following
destinations that start with a letter or a quote character and which do not
have a host specification themselves. A host name of SU-AI (or SAIL) will
override a sticky host but will not actually send the message via the ARPA
network.
There is no ARPA network standard protocol for implementing the SEND command
to a remote host. However, a private protocol for this purpose has been
implemented for use between SAIL and the ITS systems at MIT. The MAIL
program will attempt to use this protocol to any host, but it isn't going to
work except to an ITS. In particular, the designers of TENEX object to SEND
on principle, because they don't know display terminals have been invented
yet.
More information about ARPA network mail will be given in a later section.
In the #file construction, if no extension is given the default extension
of .MSG is used. To mail to a file with no extension, you must type the
filename in the form "#file." with no extension after the dot.
In the @file construction, if no extension is given the default extension
of .DIS (distribution list) is tried first. If that file does not exist,
then the null extension is tried next (both of these on your current alias
disk area unless you gave an explicit PPN). If neither of these exists,
then the extension and disk area .DIS[P,DOC] is tried (unless you gave an
explicit PPN). The [P,DOC] directory contains several distribution lists
derived from the laboratory personnel directory. For example,
SEND @VB Time for volleyball!
will send that message to all known volleyball players as listed in the file
VB.DIS[P,DOC] (see LES to be added to the list). Distribution list files
may contain E directories or SOS line numbers. Only the first page (second
page if in E format) is read. Everything on that page will be interpreted
as destinations even if not properly separated by commas. (The semicolon
format for comments will work.)
For the MAIL command, if there is a file called OUTGO.MSG in your login (not
alias) directory, it is automatically included as a destination for the
message. This provides a simple and automatic method for saving a copy of
each message you MAIL to anyone.
MAIL cannot be sent to local users who do not have file directories.
However, if you must MAIL a message to a programmer name that has no file
directories, you can do
MAIL #" prg".MSG[2,2]
to mail explicitly to the message file of programmer name "prg" (prg should
be right-justified in six quoted spaces).
The check for syntax validity and existence of local users is made as soon
as the destination list is read. If some but not all of the destinations
are valid, MAIL asks whether or not it should proceed using the valid ones.
If you want to correct a mistake in a destination (or in a switch or in some
part of the message already typed) before sending the message, answer no to
the query and then use the monitor command REENTER, as explained on page
21.
For the SEND command with a multi-line message (so the destination list is
read before the message has been entered), a warning message is given if any
programmer name recipient is not logged in. This warning does not require
reconfirmation before the command is executed.
For people who want to send mail to people listed in a file designed for use
by SNDMSG at a TENEX site, which requires a different syntax, the /ARPA
switch can be used to cause distribution list files to be parsed
differently, including the use of "@" to indicate a network host name.
Obviously nesting of distribution list files is not possible within such a
file. See the description of the /ARPA switch below for more details.
MAIL: Message Formats
Messages are usually sent preceded with a special header which tells who
sent the message and when it was sent. This header takes three forms: one
for messages being typed out on terminals (SEND command), another for local
(SU-AI) mail files, and a third for messages sent out over the ARPA network.
The header may be followed by an optional distribution list (explained
below). After the distribution list (if present), the message text is sent
followed by a blank line (unless the message already ends with a blank
line). SEND leaves off the extra blank line when typing the message on
terminals.
The header used for local files starts with a partial sign to facilitate
detection of the beginning of each message by various message editing
programs. To ensure that trouble is not caused when a partial sign actually
occurs in a message, any partial sign that occurs as the first character in
any line of a message is indented by one space, whether or not the message
is going only to local files.
Here are examples of the first two header formats:
;; Message from ME at TTY46 0032 Records
∂23-DEC-75 0032 ME Records
The SEND header (first above) contains the sender's programmer name,
terminal number, the 24-hour time of sending, and then the subject (if any).
The local file header (second above) contains a partial sign followed by the
date and the time of day, then the sender's programmer name and the subject
(if any). The local file header can be suppressed by use of the /-HEADER
switch (see the section on switches below). However, this switch is not
recommended for general use when mailing to users' message files since it
causes the message to be sent without any identification about who sent it
or when it was sent; in fact, it effectively causes the message to be
appended to some other message in the file. This switch is useful, however,
when mailing text to a special file which is simply to contain message text.
In both the SEND header and the local file header, if the sender was logged
in via the ARPA network at the time of sending, the phrase "via host" will
follow the sender's programmer name, where "host" is the name of the host
from which the sender was connected to Stanford. The name preceding the
"via ..." is, nevertheless, a Stanford programmer name.
If the sender is not logged in, his programmer name is 100 and he is asked
to supply his real name, which is included in the header.
If the message was sent to all users by a SEND * command, a "to *" phrase is
added to the header line to make it look like this:
;;Message to * from ME at TTY46 0032 Records
Finally, if the message if being sent as a reminder (see the REMIND
command), then the programmer name in the header will be followed by an
asterisk (*) as in these examples:
;; Message from ME* at TTY46 0032 Records
∂23-DEC-75 0032 ME* Records
Now, here is a sample header for messages sent out over the ARPA network:
Date: 23 DEC 1975 0032-PST
From: Martin Frost (ME @ SU-AI)
Subject: Records
To: rmf @ MIT-ML
The network header contains the date and time, the sender's real name as
well as his programmer name, the subject (if any), and the distribution list
(list of recipients of the message, starting "To:"). This is more or less
the standard ARPA network format, except for the "From:" line, which
contains the sender's real name as well as his network mailbox. The MSG
program on TENEX, which uses the "From:" line to provide an automatic reply
feature, knows about this format and handles it correctly. There is a new
mail header standard in the works, which calls for lots of useless garbage
like a supposedly-guaranteed-unique message ID line to help the bureaucrats
or the CIA or someone like that keep track of the message; we don't supply
that.
The distribution list can be omitted from network mail by use of the /NODIST
switch (see the section on switches below) and can be included in local
messages (MAIL or SEND) by use of the /DIST switch. Note that /NODIST
applies only to network messages and /DIST only to local messages. For
messages MAILed to two or more destinations, a global /DIST switch is
assumed unless a global /-DIST switch is given. The distribution list may
use more than one line if lots of destinations were specified. Also, some
destinations may be listed on lines beginning "CC:" instead of "To:"; such
destinations are considered secondary recipients of the message and are
specified by use of the /CC switch.
Normally, if a distribution list file was used to specify the recipients of
the message, a distribution list included with the message will contain only
the name of that file, not the actual recipients listed in it, to avoid very
long distribution lists. The /LIST switch (see the section on switches
below) will list in the message the individual recipients named in the file.
MAIL: Message File Formats
When mail is sent to a file which already exists, the beginning of the file
is read to see if it contains an E directory. If so, the message is added
at the end of the file preceded by a formfeed so that the message will be on
a new page. The directory is not updated to reflect this new page, but the
formfeed will be at a record boundary, so that when the file is next edited
with E, the directory can be updated without reformatting the file. If the
file does not already contain an E directory, the message is added at the
beginning of the file without any formfeed. In this case, record boundaries
are not necessarily preserved. The /APPEND switch will cause the message to
be added at the end of the file along with a formfeed as if there had been a
directory. The /-HEADER switch which omits the local mail header also omits
the formfeed which would have just preceded the header in E format files.
When a message is sent to a file which did not formerly exist, the file is
created with an initial E directory so that subsequent messages will be
added at the end of the file. The switch /-E can be used to omit this
directory normally inserted for a new file. However, this switch and its
inverse /E will be ignored for user message files (*.MSG[2,2]) and for user
plan files (*.PLN[2,2]). New user message files always get an E directory;
user plan files never do.
MAIL: Command Switches
Various switches can be specified in the command line to modify the
operation of the MAIL program. Some apply only globally; these may appear
either just after the command name or after an individual destination.
Other switches can be applied either globally (by appearing just after the
command name) or to a particular destination (by appearing just after that
destination). A switch applied to a particular destination overrides a
global switch. Switches may appear at the beginning of a distribution list
file, in which case they apply globally to all destinations within that
file. Switches appearing with the @file destination format override
file-global switches at the beginning of the file.
A switch name may be abbreviated by enough characters to identify the switch
uniquely. All switches are available in positive and negative senses (e.g.,
/LIST and /-LIST) except for the following switches which are not available
in the negative sense: /CC, /DATE, /TIME, /COUNT, and /ARPA. The default
value for most switches with a negative sense is the negative sense; the
/HEADER and /E switches are the primary exceptions, but in addition the
/SUBJECT and /DIST switches can be implied by the command.
Here are the available switches:
Switch Meaning of positive switch sense
/NOMAIL (SEND only) Do not mail the message to a destination programmer
name if the user is not logged in. Suppresses the question
about such mailing.
/YESMAIL (SEND only) Do mail the message to a destination programmer
name if the user is not logged in. Suppresses the question
about such mailing.
/MAIL (SEND only) Mail the message to a destination programmer name
as well as sending even if the user is logged in. Suppresses
the question about mailing of SEND messages which would be
asked if a destination programmer name were not logged in.
(Note that this switch has a different meaning for the REMIND
command--see below.)
/MAIL (REMIND only) Do not send the reminder to the destination
programmer name when the time comes, only mail it. Normally
reminders are both mailed and sent. (Note that this switch has
a different meaning for the SEND command--see above.)
/SEND (REMIND only) Do not mail the reminder to the destination
programmer name when the time comes, only send it. Normally
reminders are both mailed and sent.
/DIST Include the list of destinations in the text of the message for
local recipients (see message format in a previous section). A
global /DIST is implied by the MAIL command when two or more
destinations are given unless a global /-DIST is specified.
Compare /NODIST below.
/NODIST Do not include the list of destinations in the text of the
message for ARPA net recipients (see message format in a
previous section). This switch is not the inverse of /DIST!
/NO This is equivalent to /NOMAIL for the SEND command and to
/NODIST for the MAIL command, so that /N can be used to
abbreviate the appropriate switch.
/CC List this destination and all after it as secondary (CC)
recipients (see message format in a previous section). This
switch implies /DIST unless a global /-DIST is given.
/SUBJECT Include a subject line in the message. The effect of this
switch is always global. /SUBJECT is implied by the MAIL and
GRIPE commands unless some message text or the name of an
indirect message file or the /-SUBJECT switch appears on the
command line. However, typing just <CR> to the "Subject:"
prompt will omit the subject from the message. Subjects are
useful in local mail files because the first line of each page
(usually the header line of a message) appears on the directory
page in an E-format file, and for local files the subject is
included in the header line and thus in the directory.
/WHERE (MAIL and SEND only) Type the WHO line of each job that is
logged in under a programmer name included in the destinations.
/QUEUE Queue ARPA network mail for later delivery without first trying
to send it immediately. This can be especially useful if you
are sending a message to several different hosts and do not
want to wait for completion of the mail to each one. The first
attempt (by the remind phantom) to send such manually queued
mail will happen right away.
/APPEND (MAIL only) Put the message at the end of the file instead of
the beginning even if it has no directory. A formfeed will
precede the message (unless /-HEADER was given).
/LIST List the destinations specified within a distribution list file
as well as the file itself in any distribution list included
with the message. For REMIND, /LIST implies /EXPAND.
/HEADER Include the header line in messages mailed to local files. See
message formats in a previous section. Unlike most switches,
the default for this switch is on.
/E Include an E directory if creating a new message file. The
default for this switch, like that for /HEADER, is on. See the
section above on message file formats.
/DATE (REMIND, PLAN, EVENT, and BATCH only) This switch is used in
the form /DATE=<date> and sets either (1) the delivery date for
a reminder, (2) the expiration date for a plan, (3) the
occurrence date of an event, or (4) the execution date for a
batched command sequence. Reminders, events, and batch
executions can also be given a time (see /TIME switch below),
but any date must be specified before any time is. For the
<date> formats accepted, see the section below on dates and
times.
/TIME (REMIND, EVENT, and BATCH only) This switch is used in the form
/TIME=<time> and sets either (1) the delivery time for a
reminder, (2) the occurrence time of an event, or (3) the
execution time for a batched command sequence. Reminders and
batched executions can also be given a date, and events must be
given a date; see the /DATE switch above. If /DATE and /TIME
are both used, /DATE must come first. For the <time> formats
accepted, see the section below on dates and times.
/COUNT (REMIND and BATCH only) This switch is used in the form
/COUNT=<number> and sets the expiration count for a reminder or
a batched command sequence. This count is only relevant if the
command contains a wildcard date. See the section below on
dates and times.
/EXPAND (REMIND only) This switch applies only to destinations of the
form @file. It causes such a distribution list file to be
expanded now instead of when the reminder is actually sent.
This means that there will actually be a separately stored
reminder for each destination now contained in the distribution
list file rather than one reminder that actually references the
file when the reminder is being sent. This switch applies only
to the file itself (not to any @file destinations within the
file), unless the switch is given globally or file-globally, in
which case it propagates downward. /-EXPAND implies /-LIST.
/ARPA This switch may only be used with a destination of the form
@file or as a file-global switch in such a distribution list
file. It changes the syntax of the destination processor so
that the character "@" precedes an ARPA network host name
instead of a distribution list file name, and all SIXBIT
characters except space, comma, colon, quote ("), and at-sign
(@) are allowed in names without using quotes. A name ending
with a colon (distribution list name for SNDMSG) is ignored.
The switch is intended for files from systems like TENEX with
less sophisticated mail programs.
MAIL: Dates and Times
The commands REMIND, PLAN, EVENT, BATCH, and LATER all accept dates and
(except for PLAN) times. The date and/or time given for one of these
commands specifies when a particular thing should happen: REMIND causes a
reminder message to be mailed and or sent to one or more users at a given
instant; PLAN creates a plan file for the user giving the command and
specifies the date on which the plan file should automatically be deleted;
EVENT puts out a system message announcing an event of general interest
which will take place at the specified time and date; BATCH causes a
sequence of commands to be executed at the specified time and date; and
LATER causes a given program to be run at the specified time and date. For
all of these commands except LATER, there are two ways to provide the date
and time information.
The less confusing manner of giving dates and times is to use one or both of
the switches /DATE=date and /TIME=time after the command name (if both are
used, /DATE must precede /TIME). These switches may only occur immediately
after the command name. (Switches are not permitted with the LATER command,
which takes a fixed one-line format that will be explained on page 19.
Dates and times in the LATER command must use the non-switch format.) If
neither switch is used in a command that needs a date or time, then a date
and/or a time will be expected after the destination list (which is only
present for REMIND) and before the message text.
Dates may be given in any of the following formats (whether in the switch
form or not):
4/28/75 28-APR-75 APR 28, 75
4/28/1975 28-APR-1975 APR 28, 1975
4/28 28-APR APR 28
4/28/* 28-APR-* APR 28, *
*/28/* 28-*-* +3
WEDNESDAY WED W
WEDNESDAY* WED* W*
(Visitors from Europe please note that the slash format is month/day/year,
not day/month/year!)
If a specific month and day are given but no year, the current year will be
used unless the date has already passed, in which case next year is used.
Today's date is considered as already having passed except in the EVENT
command. Months and days of the week may be indicated by as many letters as
are required to identify the name uniquely. For days of the week, the
one-letter abbreviations M T W R F S D are provided. The format "+3" is
used to indicate a date of 3 days from today. The asterisks represent
wildcard dates which are explained in the section below on wildcard dates
and expiration counts.
Times may be given in any of the following formats (whether in the switch
form or not):
1423 223pm 223p 02:23p
14:23 2:23PM 2:23P 02:23PM
0223 223am 223a 223
02:23 2:23AM 2:23A 2:23
2 2AM 2PM 14
+2:23 +2: +:23 +14:
2* 2AM* 2:23* 2A*
If an explicit AM or PM is given, it must follow the time number with no
intervening spaces! This requirement is necessary to distinguish the AM or
PM from the possible beginning of the message text or of a destination name.
Times with three or four digits and no colon normally imply AM if less than
1200 and PM otherwise (the allowable range is 0000-2359); it is possible to
specify AM or PM explicitly, however, if the number is in the range
0100-1259. If no explicit date is given in the command, times with one or
two digits, or with a colon, and in the 1:00-12:59 range without an explicit
AM or PM, will represent the nearest such 12-hour time which has not yet
passed (which might be this morning, this afternoon, or tomorrow morning).
If a date is given as well as a time, times in the 0:00-11:59 range will
normally be considered AM and 12:00-23:59 will be considered PM as for the
four-digit times. Note: A time of 12:00am is midnight, and 12:00pm is noon;
the mnemonic is that 12:00 is a minute before 12:01.
If a time is given but no date, today's date is used unless the given time
has already passed, in which case tomorrow's date is used. If a date is
given but no time, the time used is midnight at the beginning of the given
date.
The relative time format (e.g., +2:23) specifies the length of time before
the command is to be executed (in this example, 2 hours and 23 minutes);
this format may only be used if no date is given and, except in the switch
form, must contain a colon so that +2 days can be distinguished from +2:
hours.
A time followed by an asterisk represents the given time and a wildcard
date; see the section below on wildcard dates and expiration counts.
MAIL: Wildcard Dates and Expiration Counts
As demonstrated in the example dates and times above, an asterisk (*) can be
used as a wildcard in place of the month or year, or following a day of the
week or a time. Such dates and times cause the command to be executed
repeatedly until exhaustion of the expiration count, which is explained
below. (Wildcard dates are not permitted in the PLAN and EVENT commands.)
An asterisk used in place of the month will cause the command to be repeated
once every month, and an asterisk used in place of the year will cause
yearly repetition; asterisks used for both the month and the year will cause
monthly repetition every year on the given day of the month. An asterisk
following a day of the week will cause weekly repetition on the given day of
the week. An asterisk following a time will cause daily repetition at the
given time; in this format no date can be given.
If * is used for the month but not for the year, the command will expire at
the end of the specfied year, or the current calendar year if none is
specified.
When a wildcard date is used, the command is repeated until exhaustion of
the expiration count. The expiration count can be set explicitly by using
the /COUNT=n switch (global only) or by following a non-switch-format
date/time with #n, where n is a decimal number. If no expiration count is
given, the default of 50 is used. A count of 0 or ∞ will prevent the
command from expiring unless it is explicitly cancelled by the user.
MAIL: Mail to Other ARPA Network Hosts
Mail can be sent to users of other computer systems connected to the ARPA
network. To send network mail, you must tell the MAIL program the name of
the recipient, as understood by the other host, and the name of the host.
Each host has an official name, a string of letters, digits, and hyphens.
For example, our host name is SU-AI. Hosts may also have unofficial
nicknames; we assign a short name to every host on the network. Either the
official name or the nickname can be used to identify a host; you need only
type enough characters to identify the host uniquely. For example, we have
the nickname SAIL which can (as of this writing) be abbreviated SA. Each
host also has a number; you can type a decimal host number instead of a
name. The format for a network destination is
name % host
where "name" is the recipient's name at the host and "host" is the host name
or number. The recipient name can contain upper and lower case letters,
digits, and hyphens; if any other characters are required the name must be
enclosed in quotation marks ("...") or downarrows (↓...↓). The name must
also be quoted if it does not start with a letter. Some hosts may consider
the case of letters significant in their user names.
To send a message to several users at the same host, it is possible to
specify a sticky host with a pseudo-destination of the form
% host
Thus, the command
MAIL FEINLER%BBNB,%AI KLH,TK,MINSKY,BH%SAIL,PAPERT
will mail the message to these recipients:
FEINLER at host BBN-TENEXB
KLH at host MIT-AI
TK at host MIT-AI
MINSKY at host MIT-AI
BH at host SU-AI
PAPERT at host MIT-AI
Of course, mail to SU-AI is not actually sent via the ARPA network! The
sticky host specifier "%AI" was not followed by a comma in the example
above; the comma is optional following sticky hosts since the use of a
sticky host implies that at least one destination will follow.
Not all network hosts are servers; that is, some hosts can originate network
connections but do not accept connections originated from another host.
Mail can only be sent to servers, and the MAIL program will refuse to try to
mail to a host which is not known to be a server. We are supposed to be
notified promptly of host status changes, so our host tables should be up to
date most of the time, but if MAIL does not recognize a host you think it
should, consult a system programmer. MAIL will always accept hosts
specified by number.
Network mail may not be delivered successfully on the first try, because the
other host or the network communications equipment may be down. Therefore,
the result of a network mail attempt is reported with one of three messages:
USER at HOST -- ok
USER at HOST -- refused
USER at HOST -- queued
The first message means that the mail was sent and acknowledged by the other
host. The second means that the network connection was established but the
other host rejected the mail, for example, because it did not recognize the
recipient as a user of that system. Usually the other host will send back a
message explaining why the mail was refused, which the MAIL program types
out. The third message means that the network connection could not be made
or was interrupted. The message is queued like a reminder and is
automatically retried at three-hour intervals for three days. (The first
repeat attempt is made 15 minutes after the original failure.) You can use
the RETRY command (see the section on the RETRY command) to retry your
queued mail manually. You will be notified via MAIL and SEND of the
eventual disposition of queued mail; the possibilities are
Mail to USER at HOST -- ok
Mail to USER at HOST -- refused
Mail to USER at HOST -- expired
The last of these means that the three-day limit ran out without a
successful connection.
When a message which was typed in from the terminal (not read from a file)
is queued, the message text is also written in a file named FAILED.TXT in
your login (not alias) directory. This file is not necessary for the
operation of the queuing system, but can be used if you want to redirect the
message. (For example, you might know that the recipient is also accessible
through another host.)
Also, you can selectively delete queued mail requests by using the monitor
command CANCEL (see page 24).
The header format for network mail is different from that used for local
mail. The section of this document on message formats explains the network
header. In particular, the distribution list (list of recipients of the
message) is by default included in network mail but not local mail. The
/NODIST switch will eliminate the list from network mail.
If you often communicate with users at other hosts, you may want to send
mail to a group of people listed in a file which was prepared elsewhere. To
make this easier, the switch /ARPA applied to a distribution-file
destination causes the file to be scanned using the syntax of the SNDMSG
program on TENEX systems. Specifically:
The character "@" is used instead of "%" to indicate network host
names.
Any character may be used in a recipient name except space, carriage
return, linefeed, tab, quote, colon, comma, and at-sign without
quoting the name. Note in particular that semicolon is a valid
recipient name character.
A recipient name ending with colon (distribution list name) is
ignored completely.
If you are sending mail to several users at other hosts, it can be very
time-consuming to wait for all the network connections to be made. The
/QUEUE switch can be used either globally or for individual recipients to
tell MAIL to queue the message immediately, without trying to send it. In
this case, the first attempt will be made essentially immediately instead of
15 minutes later, but the attempt will be asynchronous with your own job.
Note: during busy hours there may be no job slot available for the remind
phantom, in which case the mail will not be sent immediately if /QUEUE is
used.
There is no ARPA network standard protocol for implementing the SEND command
to a remote host. However, a private protocol for this purpose has been
implemented for use between SAIL and the ITS systems at MIT. The MAIL
program will attempt to use this protocol to any host, but it isn't going to
work except to an ITS.
MAIL: The MAIL Command
The MAIL command is used to send a message to one or more users, but can
also be used to write a message in an arbitrary disk file. This command
takes a list of destinations which determines where the message is to go.
See the section above on destination lists.
Mail sent to a user will be seen when he next reads his message file, but a
note saying that mail has arrived is typed out on the terminal of each
destination user who is logged in at the time the mail is delivered. You
can edit your message file with E by giving the monitor command ETV ∂ (or
ETV \MAIL).
A notice can be mailed to the system message file NOTICE.TXT[2,2] via the
MAIL * command. Users see the system messages when they log in. Since a
system message may only be relevant for a short time, an expiration date can
be specified for such a notice. To do this, use the /DATE=<date> switch;
the message will be deleted at the midnight that begins the given date, and
therefore the notice will last be seen on the previous day. The date must
not be wild; that is, it cannot contain the asterisk (*) wildcard specifier.
System messages specified without an expiration date will be deleted after
14 days. (The expiration facility is implemented by including the
expiration date as its octal DAYCNT number in the message header. A program
run every midnight deletes expired notices.) See also the EVENT command for
putting notices about events in the system message file.
Sometimes mail cannot be delivered to a given user right away. In this
case, the mail system queues the message for later delivery. Attempts to
deliver queued local mail will be made every ten minutes for four hours,
with the first such attempt occurring about 2 minutes after the original
failure. Queued network mail is retried every 3 hours for three days,
starting 15 minutes after the original failure. When the message is finally
delivered, or after 24 delivery failures, the sender is notified via the
mail system of the eventual outcome of his mail attempt. Mail will have to
be queued if the destination user is located at another ARPA network host
and that host is down, or if the destination user is at Stanford and is
currently reading his mail file. Queued mail is handled automatically by
the mail system and the sender need never take any further action. However,
the sender can unqueue any of his outgoing messages that have been queued;
the monitor command CANCEL allows selective deletion of these queued mail
requests (see page 24). Also, the sender can cause MAIL to retry sending
his outgoing queued mail immediately by giving the RETRY command (see page
18).
MAIL: The SEND Command
The SEND command is used to have a message typed out on one or more
terminals. This is usually for the purpose of sending a brief message to
the terminals of selected users so that they will see it immediately. The
message is preceded by a header telling who sent the message and when; see
the section above on message formats. This command takes a list of
destinations which determines where the message is to go. See the section
above on destination lists.
A message can be sent to all logged in users via the SEND * command. The
message will be typed out on the terminal of every logged in user.
Also, the command SEND ARPA* will send a message to all users who are logged
in at Stanford via the ARPA network.
There is no ARPA network standard protocol for implementing the SEND command
to a remote host. However, a private protocol for this purpose has been
implemented for use between SU-AI and the ITS systems at MIT. The MAIL
program will attempt to use this protocol to any host, but it isn't going to
work except to an ITS. When a SEND fails to a remote host for any reason,
the message is never queued for later delivery--its delivery is simply
aborted.
MAIL: The REMIND Command
The REMIND command allows the delivery of a message to be delayed until a
particular date and time, and/or to be repeated periodically. This command
requires a date and/or time, which are interpreted as explained above in the
section on dates and times.
Reminders are normally both mailed and sent at the specified date and time.
However, either of the switches /MAIL and /SEND can be used with the REMIND
command to cause the reminder to be only mailed or only sent. Nevertheless,
if a repeated reminder is being sent for the last time because its
expiration count has run out, it is always mailed even if /SEND was used in
the command.
When a repeated reminder's expiration count runs out, a warning message to
that effect is included in the text of the last reminder.
To selectively delete reminder requests, use the monitor command CANCEL (see
page 24).
MAIL: The GRIPE Command
Complaints, compliments, or criticisms about any aspects of the system or of
the A.I. Lab in general can be entered in the general gripe file by use of
the GRIPE command. This command takes only global switches and message
text. The gripe file can be typed out with the system program COPY by
giving the monitor command TYPE \GRIPES (which may currently be abbreviated
TY\G). This file can be examined and edited with the E editor by giving the
monitor command ETV \GRIPES (currently abbreviatable as ET\G).
MAIL: The EVENT Command
Messages of interest to everyone can be sent to the system message file by
use of the command MAIL *. However, for a message about an event occurring
on a particular day, a more useful facility is provided by the EVENT
command, which also enters the message in the system message file
NOTICE.TXT[2,2], but which does so several times: first on the day the EVENT
command is given, then again on the day before the event, and finally on the
day of the event. The EVENT command takes an explicit date and optional
time in the formats explained in the section on dates and times. EVENT will
then list the message given prefixed by a special line of the form:
Event of DAY DD-MON-YY at HH:MMxm
where DAY is the day of the week the event will occur on, DD-MON-YY is the
day, month, and year of the event's date, HH:MM is the event's time, if
given, and xm is either "am" or "pm" for the time. Thus, the date and time
need not be included in the message text itself.
On the day before the event and again on the day of the event, the event
notice will be deleted and re-entered in the notice file so that users will
see it again on those days. It is finally deleted at the midnight that ends
the day of the event. If the event is on a Monday, the notice is re-entered
on the preceding Friday, Saturday, Sunday, and the Monday of the event. If
the event is on a Sunday, the notice is re-entered on Friday, Saturday, and
the Sunday of the event. Events on other days are just re-entered on the
day before the event and the day of the event. (The re-entering of upcoming
events is implemented by including more than one expiration date in DAYCNT
format in the message header.)
If you want to change the text in an event notice, you can do a RCV * and
edit the message text or time of the event. However, if the date of the
event is wrong, you should delete the notice (with RCV) and make a new one
(with EVENT) because the octal dates in the header determine what days the
message will be seen, and the header cannot be edited.
MAIL: The PLAN Command
The PLAN command is used to create or delete a file describing your
whereabouts, office schedule, or whatever, to be read by users who give the
FINGER command to find you when you are not logged in. The PLAN command
writes a plan file called " PRG".PLN[2,2], where PRG is your programmer
name. Any previous plan file is replaced with a new one containing only the
new message you give. If you enter a null plan, your plan file is deleted.
The plan applies to your login programmer name.
The PLAN command requires an expiration date (but no time) as explained in
the section on dates and times. Your plan file will be deleted at the
midnight that begins the expiration date. (Plan file deletion is
implemented by entering a LATER request (see page 19) to run the program
DELPLN, which will delete your plan file. You can selectively delete this
LATER request by using the monitor command CANCEL--see page 24).
Your plan file can be referenced with the COPY program by using the \PLN
filehack. For instance, the monitor command TYPE \PLN will type out your
plan file, and DELETE \PLN will delete it. Also, the COPY/E message-file
specifier, partial-sign (∂), can be used to reference your own or someone
else's plan file: TYPE ∂.PLN will type out your own plan file and
TYPE ∂ME.PLN will type out the plan file belonging to programmer name ME.
MAIL: The RETRY Command
The RETRY command is used to retry all queued mail immediately. It takes no
arguments at all in the command line. RETRY searches the remind queue for
queued mail (not reminders) from or to your login programmer name and tries to
send the mail. (This will be done automatically without using the command,
but the command is provided for impatient mailers.) Please do not type
<call> or ↑C after giving this command, or you may lose a queued message.
RETRY/INPUT retries only incoming mail to you; RETRY/OUTPUT retries only
outgoing mail from you. The former is useful if you have some outgoing
network mail queued for a host which is down, and you want to see a message
which someone sends you while your mail file is busy. A full RETRY would be
time-consuming because attempting network mail to a non-responding host
is a lengthy process.
MAIL: The LATER Command
The REMIND command, in essence, allows the execution of a MAIL or SEND
command to be delayed to a specified time. The LATER command generalizes
this delayed execution to allow an arbitrary program (dump file) to be run
at a later time. The command format is:
LATER dumpfile core datetime count
The LATER command does not accept switches and requires all of its arguments
to be on the command line. If the proper syntax is not followed, a message
is typed explaining the proper syntax and nothing else is done.
The defaults for the program file to be executed are device DSK,
extension .DMP, and your alias PPN. If a device is explicitly specified, it
must be DSK or SYS. No check is made when the command is given to ensure
that the specified file exists or is a valid program dump file.
The optional core argument can be used to control the core size and starting
address used to run the program. If this argument is not used, the program
will be run in as much core as is needed to fit it, and will be started at
its normal starting address. The core argument can be in any of these
formats:
<nK> <+m> <-m> <nK,+m> <nK,-m> <+m,nK> <-m,nK>
The angle brackets are actually to be typed. The nK subargument specifies
the number of 1024-word blocks of core to be assigned to the program; n is a
decimal integer. The +m or -m subargument is a starting address offset,
that is, m will be added to or subtracted from the program's normal start
address. Note: m is an OCTAL integer.
The date and/or time must be given in the non-switch format as explained in
the section on dates and times. If both a date and a time are given, the
date must appear first.
The optional count argument specifies the number of times the program is to
be run and is ignored unless a wildcard date is used. If no explicit count
is given when a wildcard date is used, the default count of 50 will be
assumed. The format for the count field in the LATER command is
#n
where n is a decimal integer. A count of #0 or #∞ will cause the count
never to run out.
When a program specified by a LATER command is actually run, it will have
your login PPN as its login and alias PPNs. The only privilege it will have
will be the Local User Privilege (LUP). Also, it is run as a phantom
job--if it is stopped because of an error, the job is killed.
Certain accumulators (ACs) are set up when the program is started to
communicate information from the remind phantom to your program:
AC Contents
1 filename of program dump file (same as job's name)
2 extension of program dump file
3 PPN of program dump file--[1,3] if device SYS was specified
4 -1 if this LATER request will not be run again, else 0
The program can only be run if a job slot is available at the time for which
it is scheduled. If the remind phantom is unable to run the program because
no job slots are available, it does not try again later (unless, of course,
the date and time specify repetition). If the system is so crowded that job
slots are in short supply, users who are present in the flesh get priority
over LATER requests. This is rarely a problem except for weekday
afternoons. (If there is no job slot for the remind phantom itself, it will
try to run your request once, as soon as it is run itself.)
LATER requests can be selectively deleted by using the monitor command
CANCEL (see page 24).
MAIL: The BATCH Command
Sometimes you may want to delay the execution of one or more monitor
commands. To allow this, the BATCH command accepts a command string and
enters a request to run a program which enters the commands through a
pseudo-teletype (PTY). The message given with the BATCH command is taken to
be the command or sequence of commands which is to be typed to the PTY. The
only switches permitted are /DATE, /TIME, /COUNT, /NOW, and /DO. The /COUNT
switch specifies the number of times the command sequence is to be executed
and is ignored unless there is a wildcard date. The /NOW switch causes
BATCH to execute the command sequence as soon as you have finished entering
it instead of later; in this case no date or time must be given. The /DO
switch causes certain character conversion to be done when entering the
commands, as in the DO program and as explained below.
Character Effect in /DO mode
RETURN ignored
LINE ignored
↔ translated to RETURN followed by LINE
↓ translated to LINE
≠ translated to ALT
λ translated to deferred CALL (one ↑C)
VT adds CONTROL bit to following character
α adds CONTROL bit to following character
FORM adds META bit to following character
β adds META bit to following character
⊗ translated to ESC
⊗- translated to BREAK
! no-wait mode, see below
≡ quote the following character (no translation)
Note that the characters | and ? which have special meanings in the DO
program are not treated specially by the BATCH/DO command.
If the /NOW switch is not used in the BATCH command, BATCH writes a file on
your alias disk area called BATn.DMP (n is a number chosen to make the name
unique) and enters a LATER request for the running of that program. The
BATn program types the desired commands into a pseudo-teletype (PTY) when it
is run. The LATER request starts the BATn program at one more than its
normal start address; if it is started normally (e.g., RUN BATn), it simply
types out the commands stored in it, so you can find out which BATCH program
is which if you enter more than one. When the BATn program is started by
the LATER request, it writes a file called BATn.LOG on your login disk area
with a log of the commands and typed output. The BATn.DMP file is deleted
when the request is being run for the last time.
If BATCH/NOW is used, no BATn.DMP file is written. The MAIL program itself
executes the command sequence through a PTY as soon as you have entered the
whole command sequence. In this case, the log file is called BATCH.LOG and
is written in your alias directory.
The BATCH command has a time limit feature, to ameliorate the problem of
runaway batch jobs. The feature is controlled by the /LIMIT or /TLIMIT
switch (the two names are equivalent) in the form
/TLIMIT=mins or /TLIMIT=hrs:mins
The switch is given with other batch switches, right after the command name.
The form /TLIMIT=∞ may be used for an infinite limit. THE DEFAULT TIME
LIMIT IS ONE HOUR for jobs submitted for later execution, and is INFINITE
for jobs run immediately with the /NOW switch. (Presumably the latter case
implies that the user is watching the job run and can interrupt it himself
if necessary.)
The limit applies to the job's runtime (CPU time), not realtime. The BATCH
controller takes clock interrupts every two (real) minutes to check the
controlled job's runtime, so the time limit may in fact be slightly exceeded
before the job is stopped. If the job runs over its time limit, it is
logged out immediately; the log file will end with a line saying
? BATCH: time limit exceeded.
BATCH requests can be deleted selectively by using the monitor command
CANCEL (see page 24). If you delete a BATCH request with CANCEL, the
BATn.DMP file will not have been deleted; you must delete this file
separately.
The BATCH command has many deficiencies when considered as a full batch
processing facility. There is no way to control the commands issued on the
basis of past output, no provision for aborting a command sequence if an
error occurs, no provision for mounting tapes or collecting listings. The
command is not intended as a real batch processing system, but merely as a
convenience for delaying the execution of simple commands.
The BATCH command in /DO mode now recognizes a new special character,
exclamation point (!), which inverts a flag saying whether or not to
wait for the PTY job to be ready for input before typing in commands.
Normally, BATCH will not send characters from your batch command file
to the PTY job unless that job is waiting for TTY input or for a
monitor command. That way, the typing of commands is synchronized
with the running of the program. However, this synchronization
does not work for a few programs, most notably FTP, which do not
read TTY input in the normal way and therefore are never in TTY
input wait. Here is a sample command file using the new feature:
FTP AI↔!
GET FOO.BAR←MUMBLE;FOO BAR↔
BYE↔
!SEND . FTP DONE↔
The GET and BYE commands are sent to the PTY job as soon as the !
is seen in the command file, but the SEND monitor command is not
sent to the PTY until FTP exits and the PTY job is waiting for a
monitor command.
Note 1: The first ! must be on the first line, right after the ↔,
because the carriage return would (even though not actually sent
to the PTY) cause a delay after the FTP command otherwise.
Note 2: If you put enough characters between !s to fill up the
PTY input buffer, no more characters will be sent until there is
room. If the PTY job never reads any of the characters, then
both jobs will wait forever.
Note 3: If you actually want to send a ! to the PTY, you must use ≡!
in the command file. (Note that all of this applies only to /DO mode.)
MAIL: The REENTER Error Recovery Facility
The MAIL program remembers all of its input after execution, and can be made
to repeat the command with or without modifications to the command,
switches, destinations, and message. To invoke this facility, type REENTER
to the monitor.
To use this feature while typing in the message text, you can type ↑C and
REENTER, but any text still in the line editor buffer or the TTY buffer when
you type ↑C will be lost. Unless the system is very heavily loaded, the
problem of losing text from the TTY buffer should not come up, but be sure
to type <CR> to activate any text in the line editor before typing ↑C.
Two different modes of REENTER operation are provided. If the command and
destination list were all typed on one line of input from a Stanford display
terminal, that line is loaded into the terminal's line editor and can be
edited and re-activated. In this case, the program forgets all about the
previous command and starts from scratch when the edited command is seen.
The text of a single-line message will be included in the reloaded line; no
message text will be loaded for a multi-line message, but the old text is
remembered and if the new command does not contain a message or a pointer to
a message file, the old text will be re-used. Note: the subject line is
considered part of the text, and the state of the /SUBJECT switch may not be
changed if the old text is re-used in this way.
The second mode of repeating a command is used if the destination list was
given on more than one line or from a non-display. In this case, the
command and destination list are typed and you are asked if you want to keep
the old destinations. Whether you answer yes or no, the command name and
global switches are loaded into your line editor (displays only) and new
destinations can be added on the command line. Finally, if no message text
appears in the re-edited command, the old message is used as in the first
mode. (Note: in this mode, only valid destinations are remembered from the
old destination list; in the first mode what is remembered is the actual
string of characters you typed.)
If the old text is re-used, in either mode, before sending the message the
MAIL program asks if the user wants to edit the command or the message text
with E. (Editing with E is allowed whether or not the user is at a Stanford
display, although of course it's easier to do from a display. SOS editing
is not available because SOS does not use the same SNAIL-startup conventions
as E.) In this case, a MAIL.TXT file is written and E is run as in the
<CONTROL><META>E case--return to the MAIL program is done via the
<CONTROL>XRUN command.
MAIL: Hand-Holding Mode
If a command (other than LATER and RETRY) is given with no arguments other
than optional global switches, the MAIL program will use an alternate syntax
called hand-holding mode which is more verbose but less confusing to an
inexperienced user. In this mode, MAIL will prompt separately for each
piece of information appropriate to the given command; the possible prompts
include:
"To" destinations
"CC" destinations
Date and time
Expiration count
Subject
Message text
One possibly important difference between this and the normal syntax is that
the subject line is always entered separately from the body of the message,
even if the latter comes from a file.
Each prompt may be answered by a line containing just the character "?" to
see a message explaining the format of the required information for that
prompt.
A REENTER command following the use of this format will be treated the same
as one following a multi-line destination list in the normal format.
MAIL: Interfacing to MAIL from Other Programs
The MAIL program can be run from another program using the SWAP UUO. A
special facility is provided for providing MAIL with the required arguments
via the ACs which are preserved by the SWAP UUO. To do this, start
SYS:MAIL.DMP at one less than its normal starting address. The message text
(including subject line, if desired) must first be written in a disk file,
or a TMPCOR file if the MAIL program is to be run in the same job as the
swapping program. MAIL will, if desired, SWAP back to the originating
program (or any other program). The ACs should be set up this way:
0-5 SWAP UUO arguments for return after MAIL if desired:
0 device
1 filename
2 ext,,mode bits (see UUO manual)
3 core,,starting address increment
4 file PPN
5 login PPN if starting new job
6-16 MAIL arguments:
6 destination PPN or file (see below)
7 file extension if required
10 file PPN if required
11 message text file name
12 message text file extension
13 unused
14 message text file PPN
15 date and time for REMIND (see below)
16 flags (see below)
17 is the SWAP AC and is not preserved in return after MAIL.
The flags in 16 are:
400000,,0 not used
200000,,0 /-E
100000,,0 /NODIST for ARPAnet mail
40000,,0 /LIST
20000,,0 /SEND
10000,,0 /-HEADER
4000,,0 /QUEUE
2000,,0 /APPEND
1000,,0 /DIST for local mail
400,,0 /WHERE
200,,0 /SUBJECT
100,,0 /MAIL
40,,0 /YESMAIL
20,,0 /NOMAIL
10,,0 /EXPAND
4,,0 command is REMIND
2,,0 command is MAIL
1,,0 command is SEND
774000 not used
2000 read destinations from named file (ACs 6-10)
1000 return via SWAP when done
400 text input is from TMPCOR file
200 delete input text file when done
100 send to job (binary number in AC 6)
40 send to TTY (SIXBIT name in AC 6)
20 destination is * or ARPA* (AC 6 ignored)
10 mail to explicitly named file (ACs 6-10)
4 don't use this bit (/CC)
2 /ARPA (2000 bit must also be on)
1 if SEND, send to ARPA* (20 bit must also be on)
if MAIL, delete old contents of file
(for PLAN, see below)
Nothing is guaranteed about the results of setting inconsistent or
irrelevant combinations of flags, e.g., /EXPAND for a command other than
REMIND. Note that the /MAIL switch has two different meanings for the SEND
command and the REMIND command, but is the same bit in either case. Bits
which are currently unused should be zero.
If the 400 bit in AC 16 is on, the left half of AC 11 is taken as the TMPCOR
file name; the TMPCOR file PPN is the alias PPN of the MAIL job. The 200
bit in AC 16 will delete either a DSK file or a TMPCOR file.
The usual case is sending a message to a programmer name. For this case,
AC 6 should contain zero in the left half and the sixbit programmer name
right-justified in the right half. Do not use "." for your own programmer
name (use the programmer name explicitly) nor "*" for a wildcard destination
(use 20 bit in AC 16).
Mail can be sent to any file (as in the #file destination format) by setting
the 0,,10 bit in AC 16 and specifying the filename in ACs 6-10. More than
one destination, or a recipient at another ARPA network host, must be
specified by using an indirect file as in the @file destination format; set
the 0,,2000 bit in AC 16 and specify the file with the destination list in
ACs 6-10.
Any files used (except the TMPCOR message file) must be on device DSK. No
default extensions will be used; specify the desired extension explicitly.
(The right half of an extension word must be 0.) A zero file PPN uses the
job's alias PPN as usual.
Exactly one of the 7,,0 bits should be on in AC 16 to specify the command to
be carried out. The effect of the PLAN command is achieved by specifying a
MAIL command with the delete-old-text bit and explicit file destination
(2,,11 in AC 16) and " prg.PLN[2,2]" as the destination filename in
ACs 6-10.
The date and time in AC 15 is in the format:
BYTE (4)MONTH (5)DAY (6)YEAR (3)DAY-OF-WEEK (6)HRS,MINS,FLAGS
The flags are used for special formats:
0,,1 absolute date, DAYCNT in left half
0,,2 date is tomorrow (lh is zero)
0,,4 every day reminder (lh is zero)
Otherwise, zero in the left half means today's date, a nonzero number in the
7,,0 bits is an every-week reminder (1=Wed, 7=Tues), and anything else is an
every-month or every-year reminder with at least one of the month and year
fields zero. Month 1 is January, day 1 is the first of the month, and year
1 is 1965. The HRS field is hours past midnight (0-23) and the MINS field
minutes past the hour (0-59). An absolute date (no wild fields) must be in
DAYCNT form.
Another facility is also provided for queuing MAIL requests when the SWAP
technique is inappropriate, for example because another job slot might not
be available and your program must keep itself going rather than be swapped
back in later. This facility was designed for the FTP server but can be
used by other programs. Write a file called <anything>.FTP[RMD,SYS] which
contains, in text form, a MAIL command and destination list on the first
page, and the message text on the second page. (This is the format of the
MAIL.TXT file used for editing messages with E.) When the remind phantom is
next run, it will try to start a MAIL job which will execute the command and
delete the file.
MAIL: The CANCEL Command
The monitor command CANCEL will run the CANCEL program which will list, and
allow selective deletion of, REMIND requests from or to you, BATCH and LATER
requests by you, and queued mail from you. This program can also be used to
list these requests without asking whether you want to delete them: after
any request is listed, type the letter L in answer to the deletion question
and any remaining requests will be listed without interruption. Since the
CANCEL program has to share the use of the reminder queue files with the
system reminder phantom job, there will sometimes be a delay in the listing
of reminders. An appropriate message is typed in this case.
MAIL: The RCV Command
The RCV program allows MAIL messages to be selectively deleted, listed, or
saved as desired. The program is called by simply entering the monitor
command RCV. All mail files which can be construed as being for you are
offered for your perusal. It is also possible to edit other users' mail
files with RCV by giving an argument, e.g., RCV BH. The command RCV * will
allow editing of the system message file NOTICE.TXT[2,2], and RCV GRIPE will
allow editing of messages sent by the GRIPE command. Most mail files are
maintained in E format, and E format is not preserved when such a file is
edited with RCV--therefore:
*** NOTE: IF YOU EDIT AN E-FORMATTED FILE, RCV WILL INVALIDATE ***
*** THE DIRECTORY PAGE AND ISSUE A WARNING. SUCH FILES SHOULD ***
*** USUALLY BE EDITED WITH E TO PRESERVE THE PAGES AND FORMAT. ***
RCV also allows editing of the files created by the news service automatic
notification feature; the command RCV \ will present your notifications for
editing, and RCV \PRG will allow you to edit the notifications sent to user
PRG.
It is also possible to use RCV on files not in [2,2] (such as saved message
files previously created with RCV) with a command like:
RCV #filename
with default of DSK:SAVED.MSG in your (alias) disk area. The conventions
given below for output filenames also apply here.
Finally, the command RCV ?PRG will type the plan file for user PRG, if there
is such a file. In this case, the file is merely typed, not edited.
** NOTE: ONCE RCV HAS OPENED A MESSAGE FILE, YOU SHOULD EXIT ONLY **
** BY TYPING "E" TO AN OPTION REQUEST, AS EXPLAINED BELOW. TYPING **
** <CALL> TO EXIT MAY RESULT IN LOSING SOME OF YOUR MESSAGE TEXT! **
If none of the messages in an input file is deleted or changed, RCV does not
write out a new version of the file; thus the file's time and date written
are unchanged, and, particularly, any ETV directory the file may have had is
still intact.
RCV deletes without comment all formfeed characters in any file edited (that
is, any file actually changed). Thus any page structure of such a file is
destroyed by RCV.
When a mail file is opened, messages are typed out one at a time, and for
each message you may select several processing options, in the format
<options> [ <space> <filename> ] <cr>
where the [...] represents an optional argument. Each option is represented
by a letter; more than one may be used, except that a few options must be
used alone, as noted below. The filename may be specified if you select the
C (copy) or T (transfer) option. For help in specifying a file, use ? as
the filename. Here are the option letters which select a final disposition
for the message:
S Save the message in the mail file.
D Delete it from the mail file.
C Copy it to a file of your choice.
T Transfer it to a file. Like CD.
L LPT spool it.
X XGP spool it.
K Transfer it to the file LOGOUT.MSG, which will be typed automatically
when you log out.
If none of the above are used, the message will be Saved. Combinations may
be used, e.g., LD will spool the message on the LPT and also delete it from
the mail file. The message will be Saved unless D or T is explicitly
specified. Along with any of the above (or alone, implying S) may be used
at most one of the following editing options:
A Append to the message from the terminal.
Z (Stanford displays only) Edit the message line-by-line using the
system line editor. If you need help with this facility, type
<control><meta>? after entering the line editing mode.
M (Stanford displays only) Modify the message by running the text
editor, E, with that message as its input. Return from E by typing
<control>X RUN.
Along with any of the above, or alone, can be used the following option
letters to avoid seeing more messages:
E Exit, and enter spooling requests from L or X options.
N Go to the Next mail file, if any, else exit like E.
If the message was longer than the amount RCV types out before asking for
option requests, the following option may be used along with any others
specified:
Q Quiet processing; do not type the remainder of the message while
processing it as usual.
Note: E or N with no other options implies Q automatically. Alternatively,
any of the following may be used as the only option, for special processing:
P Postpone the decision for this message. This applies only if the
message was longer than the amount RCV types before asking for
options, and you wish to see the rest of the message before choosing
options.
? Type this option list.
Spooling requested by L or X is not done until RCV is exited (by typing E to
an option request, or by running out of input). The default filename for C
and T is DSK:SAVED.MSG in your alias area. Filenames may only be given
along with a C or T option; if C or T is used without a filename the
previous file is continued. (The first time, you will be asked for a
filename, which may be simply <cr> for SAVED.MSG.)
If you use an argument in the RCV command to edit another user's mail, the
first time you specify any option which would remove a message from the mail
file or alter its contents you are asked to confirm it. Once you have
confirmed such an option, however, you are not asked again.
There are two options provided at Stanford displays for editing the text of
a message. The M option writes the message in a disk file, QQRCV.TMP, and
runs the E editor, which allows great flexibility because of E's powerful
editing capability. However, it is rather slow, because all of RCV's
internal information and all the message files must be saved on the disk.
For minor corrections to a short message, you may prefer the weaker but
faster editing capability provided in RCV itself by the Z option. If you
select that option, the lines in your message will be presented to you one
by one in your terminal's line editor. You may edit each line, using the
normal line editor commands, and type <cr> when done with a line. You may
also type the following special characters (α means control, β means meta):
α<cr> Accept the current line as it now appears in your line editor
buffer and stop line editing, accepting the rest of the message
as is.
αβD Delete the current line.
<alt> Undo the changes in this line, loading a fresh copy into the
line editor.
αβ<cr> Accept lines to be inserted before the current line, until an
inserted line is terminated with α<cr> instead of <cr>, or
<alt> is typed at a blank line.
αβI Same as αβ<cr>.
αD (at the end of a line) Combine this and the next line and load
the combined line into the line editor.
β<cr> Break the line at the cursor, accepting the text to the left of
the cursor as it stands and editing the remaining text as a new
line.
αβA Leave line edit mode, as for α<cr>, but accept text from the
terminal to be appended after the existing text, as if the A
option had been selected.
αβ? Type this list.
Blank lines presented for editing in the Z option are indicated by the
typing out of a space before loading the line editor with the empty line;
thus originally empty lines will be indented in the typeout. In both M and
Z options, the initial header line is not edited. In the Z option, the
blank line at the end of the message is not edited. In the A option,
appended text will be inserted in front of the blank line at the end of the
message, unless the P option was previously used on the current message.
The first time you specify C or T, you are asked to specify a file name if
one was not included in the option line. You can reply with either a
standard filename, ?, or <cr>. Just <cr> uses the default file name,
DSK:SAVED.MSG in your (alias) area. Just ? will print a helpful message and
let you try again. Thereafter, whatever file you specified will be used for
all C and T messages (the file is not closed until you exit or select
another one) until you specify a new filename along with a C or T option as
described above. Note: if the specified file already exists and is in E
format, the new messages are added at the end of the file preceded by a
single formfeed; if the file already exists but is not in E format, the new
messages are added at the beginning of the file. If the file does not
already exist, it is created in E format and a warning that you are creating
a new file is issued.
If all messages are removed from an input file, the file is deleted after
all output files are closed, unless the input file is named OUTGO.MSG in
which case the empty file (which may actually contain a few spaces, carriage
returns, and linefeeds) will survive. If none of the messages in an input
file is deleted or changed, RCV does not write out a new version of the
file; thus the file's time and date written are unchanged, and,
particularly, any ETV directory the file may have had is still intact.
The notation ↓chars↓ may be used to get non-alphameric characters in a
filename. In addition, a shorthand notation is provided for entering names
of mail files: if the character ∂ is the first character of the filename,
then the device becomes DSK, the default extension .MSG, and the default ppn
[2,2]. (The extension and ppn can be changed later in the filename.) If
the next non-blank character is not alphameric, the filename used is your
programmer name right justified, e.g., ↓ REG↓. (Note that this is your
own login name, not the name whose mail you are editing.) Thus, the
filename ∂ represents your own mail file. You can specify a different
programmer name with the format ∂prg and either this or the format ∂ can
also be optionally followed by an extension and/or a PPN to change the
default values as described above, e.g., ∂.PUR or ∂[1,ME].
RCV has a fairly small message buffer. If a message is longer than that
buffer, seeing the first few lines of the message may tell you enough about
it to decide how to process it without seeing the rest. Therefore, in that
case, you will see as much as fits, followed by an overflow notice and an
option request. After you enter the desired options, the remainder of the
message will be typed as it is being processed, so you may safely use the
Delete option and you will still see the rest of the message. If you want
to avoid this continued typeout, type the letter Q (for Quiet) before your
option choice, e.g., QD for Quiet Delete. Q is only recognized when a
message overflows. If you select E or N with no other options, you get Q
automatically. If this is not what you want, type, e.g., SE. If you wish,
you may postpone the decision on how to process the message until after
seeing the rest of it, by typing P to the option request. This will type
the remainder of the message and ask again for options. QP is illegal, and
P is only legal when a message overflows.
RCV may be used when not logged in; however, each user can control access to
his own mail, by OPTION.TXT options. Three possibilities are available.
The default is no access. To allow your mail to be read but not modified,
put
RCV:READ
in your OPTION.TXT file. If the not-logged-in user types RCV PRG the file
examined is OPTION.TXT[1,PRG]. You may also allow not-logged-in users to
edit your mail file as if they were logged in by using
RCV:WRITE
as the option.
Not-logged-in users at Stanford display terminals (Data Disc or III) always
have at least READ access to mail.
It should be noted that the normal file protection mechanism still applies,
so that most options which involve copying the message to another file will
not work when not logged in. This includes C, T, K, L, X, M, and P.
A not-logged-in user who is reading mail as permitted by the READ option may
safely use <call> to quit RCV.
There is a special option available in RCV for reading the A.P. news
digest. This option is provided when the RCV command is given without an
argument, if you have an OPTION.TXT file with a line of the form
RCV:DIGEST;
You are asked "Read A.P. digest?" if the digest file exists. This option
may be used along with READ or WRITE as described earlier.
Another special option available through the OPTION.TXT file is:
RCV:NOMAIL;
If you have this option and give the RCV command without an argument, RCV
ignores your main message file and simply processes any other files which it
would normally handle. This is provided for users of various special RCV
features (such as DIGEST above) who use E to edit their mail files since
mail files are now normally in E format. To override the NOMAIL option
(i.e., to edit your mail file with RCV), give your programmer name
explicitly in the command, e.g., RCV PRG.
For use at non-Stanford terminals, RCV has a mode in which it accepts tty
input in SOS representation (see Appendix 13 of the Monitor Command Manual,
in the file MONCOM.BH[S,DOC]). The main reason for this is to allow ?*
instead of ∂ for redirecting messages to another mail file, but it can also
be used with the append option to allow appending upper/lower case text from
an upper-case-only terminal. The following notes apply:
1. When RCV is started, it decides whether or not to use SOS representation
on the basis of the FCS (full character set) bit maintained for each
terminal by the monitor. This bit is set by the TTY FULL command (or ESC F
at a Stanford display) and cleared by TTY NO FULL (or BREAK F).
2. Whenever RCV reads an altmode character from the tty, it will enter SOS
mode and otherwise ignore the altmode, except that if you are already in SOS
mode the sequence ?<alt> will leave that mode. (If you are not in SOS mode,
of course, the ? will be taken as a real question mark and the <alt> will
enter SOS mode!)
3. These comments apply even to the original command line, although the
monitor will echo a crlf after the altmode to confuse you. Note that if
your FCS bit is off and you want to invoke the RCV feature which types a
user's plan file, you must say RCV ??prg instead of RCV ?prg as usual.
4. Under no circumstances is tty output done via SOS conversion. I hate
seeing all those question marks!
5. If you are in SOS mode and type ? followed by a character which is not
defined as an SOS code, the character will be treated, and echoed, as
ASCII 7; this will ring your tty's bell if it has one, give an error message
if you are responding to an option request, and insert a π in your message
if you are appending.